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(57) ABSTRACT 



A POS (point-of-sale) Check Service converts any paper 
check online and in real-time into an electronic funds 
transaction. The paper check is returned to the customer. A 
merchant enters the amount of the sale and electronically 
captures checking account data from the MICR line encoded 
on the check. The check data, identification data and sale 
amount are forwarded to a service organization for process- 
ing. The service has three options: Conversion Only; Veri- 
fication with Conversion; and Guarantee with Conversion. 
Under Conversion Only the transaction is approved or 
declined with no account verification processing and the 
merchant retain the risk of loss. Under Verification with 
Conversion the check authorization message is routed to the 
participating drawee bank or to a third-party authorizing 
agent for verification that the check will be paid. Under 
Guarantee with Conversion, the check authorization request 
message is routed to the participating drawee bank or to a 
third party to guarantee the check. A check guarantor buys 
the check from the merchant at a discount. 
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Merchant Name 
Merchant Address 
Merchant Phone 
Date: 04/04/00 
Time 11:56 
Lane #99 
Cashier #7777 

AMOUNT OF TRANSACTION: $82.35 

AMOUNT OF SALE: $62.35 

CASHBACK: $20.00 

Routing# 122101191 

Account# XXXXXX4587 

Check# 1234 

Customer’s Bank: (optionai) 

Auth: 203500 Ref# 001002 (optional) 

AUTHORIZATION AGREEMENT: 

I authorize the merchant to use the Information from my 
check to Initiate an Electronic Fund Transfer (EFT) or a 
paper draft to debit my bank account for the amount of 
the transaction. I acknowledge and agree that the 
merchant-initiated EFT is not a check transaction, and Is 
governed by applicable EFT law. in the event that the EFT 
or draft Is returned unpaid, i understand and agree that 
the merchant may charge a return fee to my bank 
account. 

X 

Authorization Signature 
Customer Service Number 

Top Copy — Merchant 
Bottom Copy — Customer 
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POINT OF SALE CHECK SERVICE 

[ 0001 ] This application claims priority of U.S. provisional 
patent application No. 60/225,566 filed Aug. 14, 2000, of 
provisional patent application No. 60/227,712 filed Aug. 24, 

2000, and of provisional patent application No. 

(Atty Docket No. VISAP062PX2) filed Feb. 22, 2001, 
which are all hereby incorporated by reference. 

FIELD OF THE INVENTION 

[ 0002 ] The present invention relates generally to financial 
transactions. More specifically, the present invention relates 
to an online, real-time point-of-sale check authorization 
system. 

BACKGROUND OF THE INVENTION 

[ 0003 ] Paper checks count for over 50% of U.S. personal 
consumption expenditures. The handling and processing 
cost of paper checks at the point of sale, as well as the costs 
and losses associated with checks, presents significant loss 
to merchants and the depository institutions who accept 
these checks. In 1999 alone, consumers wrote an estimated 
19 billion checks at the point of sale. Check handling costs 
and losses for merchants are estimated at $23 billion per year 
and in 1999 this was an average of more then $1.00 for every 
check written at the point of sale. Some estimates place bank 
costs for processing checks at close to 20% of non-interest 
expense. 

[ 0004 ] For banks, these check processing costs are the 
single largest segment of non-interest related expense, total- 
ing more than $40 billion in cost for all checks and approxi- 
mately $11 billion dollars for point-of-sale checks alone. 
Merchants spend about $10 billion in acceptance and depos- 
its of paper checks. Merchants’ losses from acceptance of 
checks, with fraud and other reasons, total more than $12 
billion dollars. 

[ 0005 ] In today’s merchant market, check authorizations 
are performed by a host of third-party, non-bank competitors 
who authorize checks using various combinations of nega- 
tive-file and credit-bureau positive information often in 
conjunction with neural models, to advise merchant clients 
of the likelihood that a check will clear the settlement 
process once it is posted. The third-party information system 
uses check and consumer account data without paying banks 
for that data. These third-party check authorize rs have also 
begun pilot offerings in which the paper check is truncated 
at the point of sale and converted into an ACH item for 
settlement. 

[ 0006 ] Although there are notable advances in the prior 
art, the available references do not provide an adequate 
solution to the cost and difficulty of processing paper checks. 
Most relevant references are U.S. Pat. Nos. 5,832,463, 
5,703,344 and 5,175,682. 

[ 0007 ] U.S. Pat. No. 5,832,463 discloses a system for the 
real-time conversion of checks issued by a participating 
bank or through an Automated Clearing House (ACH) 
transfer. This system is inapplicable for participating drawee 
banks. For non-participating banks, a paper check must be 
processed. The system is closed and only handles checks 
from institutions that are part of the EDS system. This 
system is for Conversion Only; the system does not teach or 
suggest the real-time verification or guarantee of checks at 
the point of sale. 



[ 0008 ] U.S. Pat. No. 5,703,344 discloses a real-time, 
point-of-sale check confirmation and guarantee system that 
uses VisaNet for checks issued by member or non-member 
third-party institutions. This system does not involve check 
conversion and only discloses batch processing of checks. 
Further, this system does not disclose real-time check con- 
versions. 

[ 0009 ] U.S. Pat. No. 5,175,682 discloses a system of 
processing checks by verifying and converting in either 
batch mode or in real-time if certain predefined circum- 
stances are present. There is no online access to demand 
deposit accounts nor online, real-time access for any bank. 
The system does not disclose the real-time guarantee of any 
personal checks. 

[ 0010 ] U.S. Pat. No. 5,053,607 discloses a point-of-sale 
device only and has no details concerning a payment infra- 
structure. U.S. Pat. No. 5,532,464 discloses an electronic 
check presentment system but still involves the processing 
of a paper check. U.S. Pat. No. 6,006,208 discloses a system 
for making a payment by telephone. U.S. Pat. No. 5,484,988 
discloses check clearing through an ACH transaction which 
is batch driven and not in real-time. Further, conversions are 
not performed online, in real-time against any possible bank. 
U.S. Pat. No. 5,963,219 discloses a system for generating 
electronic checks. There are no paper checks involved at all 
and there is no conversion of paper checks occurring. 

[ 0011 ] It is desirable then for a point-of-sale check service 
to be able to authorize checks online and in real-time for any 
possible bank upon which a check is drawn. 

SUMMARY OF THE INVENTION 

[ 0012 ] To achieve the foregoing, and in accordance with 
the purpose of the present invention, a POS (point of sale) 
Check Service is disclosed that converts paper checks online 
and in real-time into an electronic funds transaction. This 
service will significantly reduce paper check processing 
costs for member banks and merchants. Advantageously, the 
service accepts any paper personal check from any bank, and 
authorizes it online, in real-time at the point of sale. The 
paper check is returned to the consumer for his or her 
records. It is not necessary for the merchant to keep the 
paper check. 

[ 0013 ] The service operates in real-time over a data com- 
munications network and does not need to rely upon voice 
communications. Also, unlike a typical ACH transaction 
which may take 48 hours, check authorization can occur in 
a matter of seconds. No PIN (personal identification num- 
ber) is required to be entered, and the system can process a 
check from a participating bank or from a non-participating 
bank. 

[ 0014 ] It is estimated that by routing and processing 
electronic check transactions, banks and merchants will 
eliminate billions of dollars in annual paper check handling 
costs. Thus, a benefit of the POS Check Service is signifi- 
cantly reducing paper check processing costs for banks and 
merchants. For acquiring banks, the POS Check Service 
leverages existing payment networks and infrastructure and 
adds a new source of revenues for all points of sale. For a 
merchant, the POS Check Service lowers the cost of check 
processing, reduces risk because paper check handling is 
eliminated, speeds customer checkout, provides more efh- 
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cient clearing and settlement, reduces losses by providing 
options for check guarantee or verification, and lowers check 
losses by retrieving online check authorizations directly 
from the bank on which the check is drawn. For a partici- 
pating drawee bank, the POS Check Service provides an 
opportunity to authorize checks, allows use of existing 
infrastructure to convert paper checks to electronic transac- 
tions, and greatly reduces the cost of processing checks. For 
the customer who writes the check, the POS Check Service 
provides transaction details that can be included on a 
monthly bank statement, enables faster checkout, returns the 
voided check and sales draft receipt to the customer, and also 
improves security because the check is returned to the 
customer at the time of the transaction. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0015] The invention, together with further advantages 
thereof, may best be understood by reference to the follow- 
ing description taken in conjunction with the accompanying 
drawings in which: 

[0016] FIG. 1 illustrates an embodiment of the POS 
Check Service authorization and clearing system. 

[0017] FIG. 2 is a flow diagram describing the overall 
POS Check Service flow. 

[0018] FIG. 3 is a flow diagram describing the setup 
procedures for the POS Check Service. 

[0019] FIG. 4 is a more detailed illustration of a paper 
check. 

[0020] FIG. 5 is a flow diagram describing how a request 
is initiated to convert a check at the point of sale. 

[0021] FIGS. 6A, 6B and 6C are a flow diagram describ- 
ing the authorization and clearing of a transaction. 

[0022] FIG. 7 is flow diagram describing the completion 
of a transaction at the point of sale. 

[0023] FIG. 8 illustrates an example of a transaction 
receipt printed at the point of sale. 

[0024] FIG. 9 is a flow diagram describing the settlement 
of transactions. 

[0025] FIG. 10 illustrates the settlement process for trans- 
actions settled via the service organization or switch. 

[0026] FIG. 11 illustrates the settlement process for POS 
Check Service transactions via the ACH. 

[0027] FIG. 12 illustrates a settlement flow for a partici- 
pating drawee bank. 

[0028] FIG. 13 illustrates a settlement flow for a non- 
participating drawee bank. 

[0029] FIG. 14 illustrates an alternative settlement flow 
for a non-participating drawee bank. 

[0030] FIG. 15 illustrates an example of an authorization 
and settlement flow in which the acquirer and the drawee 
bank are the same. 

[0031] FIG. 16 is an example of an authorization flow in 
which the acquiring bank is not the same as the drawee bank. 



[0032] FIG. 17 is an example of an authorization flow in 
which the customer’s check is to be drawn on a bank which 
does not participate in the POS Check Service. 

[0033] FIG. 18 is an example of an activity report for a 
participating drawee bank. 

[0034] FIG. 19 illustrates a telecommunications network 
suitable for implementing an embodiment of the present 
invention. 

[0035] FIG. 20 illustrates systems housed within an inter- 
change center to provide online and offline transaction 
processing. 

[0036] FIG. 21 illustrates another view of the components 
of the telecommunications network. 

[0037] FIG. 22 illustrates in more detail a suitable hard- 
ware embodiment for the POS Check Service. 

[0038] FIGS. 23A and 23B illustrate a computer system 
suitable for implementing embodiments of the present 
invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0039] A merchant first initiates a POS Check Service 
transaction by entering the amount of the sale and by passing 
the check through a reader to electronically capture checking 
account data from the magnetic ink character recognition 
(MICR) line encoded on the customer’s check. The mer- 
chant can optionally key enter customer identification infor- 
mation, such as a driver’s license number, at the point of 
sale. The check data, identification data and sale amount are 
combined with other data elements and forwarded to a 
service organization for processing. As another option, the 
merchant decides whether to send all transactions through 
the Service or only participating transactions through the 
Service. For a merchant opting to send only participating 
transactions through the Service, the service organization 
may distribute routing tables which the merchant can use to 
identify participating transactions. These transactions would 
be cleared and settled through the service organization. In 
this instance, these transactions would never be routed 
through the ACH. 

[0040] The service begins by swiping the check through a 
check reader at the point of sale. The transaction is formatted 
into a check authorization message and one of three service 
options is selected automatically or manually: Conversion 
Only; Verification with Conversion; or Guarantee with Con- 
version. Under Conversion Only the transaction is approved 
or declined without the requirement of account verification 
processing, and the merchant retains the risk of loss. Under 
Verification with Conversion, the check authorization mes- 
sage is routed to the participating drawee bank or to a 
third-party authorizing agent for verification of the prob- 
ability that the check will be paid. The authorizing agent can 
accept or decline based on access to the demand deposit 
account (DDA) and/or the third-party risk management 
database. Again, the merchant retains the risk of loss. 

[0041] Under Guarantee with Conversion, the check 
authorization request message is routed to the participating 
drawee bank or to a third-party authorizing agent to guar- 
antee the check. A check guarantor effectively buys the 
check from the merchant at a discount, eliminating the risk 
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of loss to the merchant. The guarantor makes an accept or 
decline decision, based on access to the DDA account and/or 
to a third-party risk management database. The guarantor 
bears the risk of loss. 

High Level System Description 

[0042] FIG. 1 illustrates POS Check Service authorization 
and clearing system 100. System 100 is used to convert a 
paper check at the point of sale into an electronic transaction 
and to authorize and clear the check. Customer 102 wishes 
to perform a transaction with a merchant 104 using a paper 
check 106. Merchant 104 is any entity that accepts consumer 
checks in payment for merchandise or services. Check 106 
is any suitable paper personal check presented to a merchant 
in payment for a purchase. Check 106 may be completely 
filled out by the customer or it may be completely blank, 
having only identifying characters along its lower edge for 
reading by a device. Although check 106 may be any 
suitable paper check, under current NACHA (National Auto- 
mated Clearing House Association) rules, certain checks 
may not legally be used, although technically their use is 
feasible. For example, under NACHA rules, checks such as 
corporate checks, government checks, traveler’s checks, 
checks not linked to an ABA demand deposit account, 
checks drawn on invalid ABA numbers, etc., are not cur- 
rently accepted within the system. Notwithstanding the 
above, it is contemplated that as rules are changed, the 
system may accept additional types of checks. 

[0043] Present at the point the sale are any number of 
devices that assist the merchant with reading information 
from the check and with acquiring information from the 
customer. Preferably, a MICR (magnetic ink character rec- 
ognition) device 110 is used to read identifying information 
from check 106. Alternatively, other devices may be used to 
either read information from the check or to receive iden- 
tifying information needed to identify the checking account 
from which the customer wishes money to be withdrawn. 
For example, an OCR device 112 may be used to read 
information from check 106. In other embodiments, check 
106 is not present and the customer presents other suitable 
unique information to identify the checking account from 
which he or she wishes money to be withdrawn. For 
example, biometrics reader 114 may be used to uniquely 
identify the customer and a particular checking account, and 
checking account information would be contained at a 
central database. A convenience card is another way to link 
an account number to a consumer. 

[0044] Further keypad 108 may be used by the merchant 
or customer to enter not only identifying information for the 
checking account, but also information concerning the trans- 
action amount and any other customer identifying informa- 
tion. Keypad 108 may be combined with any of devices 
110-114, may be incorporated into a cash register, may be 
part of a computer, or may be a standalone device. In a 
preferred embodiment, the merchant swipes check 106 
through MICR device 110 which is incorporated into a cash 
register. 

[0045] Acquiring bank 120 is a financial institution that 
contracts with the merchant and directly or indirectly sub- 
mits check transactions for authorization, clearing and 
settlement. A processor may also perform these functions on 
behalf of the acquirer — both are hereinafter referred to as the 



acquirer or the acquiring bank. Service organization 122 
(also termed the ''switch” is a financial service organization 
that accepts messages from acquirer 120 and routes them to 
either drawee bank 124 or to third party 126. Service 
organization 122 may be any suitable organization for 
performing clearing and settlement such as MasterCard, 
American Express, Discover, etc. In a preferred embodi- 
ment, service organization 122 is Visa U.S.A. Inc. of San 
Francisco, Calif. 

[0046] Drawee bank 124 is a customer bank that is par- 
ticipating in the POS Check Service and is connected online 
via a network to service organization 122. The drawee bank 
is where the customer maintains his or her checking account, 
and the bank issues checks to the customer. Alternatively, a 
processor may act on behalf of the drawee bank-both are 
referred to hereinafter as the drawee bank. Third-party 
authorizing agent 126 is an entity that authorizes POS Check 
Service transactions for non-participating banks and creates 
the corresponding ACH transaction. 

[0047] FIG. 2 is a flow diagram describing the overall 
POS Check Service flow. Initially, various setup procedures 
are preformed by or for the merchant, the acquirer, the 
drawee bank, the third party and the service organization. 
These steps typically occur before the service is operational 
and before a customer performs a transaction. A customer 
presents a paper check as part of step 154 in which a request 
is initiated for clearing and settlement; this step is explained 
in greater detail below. 

[0048] In step 158 system 100 performs authorization and 
clearing of the transaction in order to indicate to the mer- 
chant whether the transaction is authorized or not; this step 
is explained in greater detail below. In step 162 the trans- 
action is completed at the point of sale depending upon the 
results returned. Finally, the transaction is settled in step 166 
between the acquirer and either the participating drawee 
bank or a non-participating bank. 

Detailed Flow Description 

[0049] FIG. 3 is a flow diagram describing the setup 
procedures for the POS Check Service. The setup proce- 
dures typically occur before the POS Check Service is 
available to conduct a transaction. Regarding the point of 
sale, there are various tasks a merchant performs in order to 
be ready to convert a check at the point of sale. For example, 
a merchant installs devices at the point of sale that can read 
MICR, OCR or other data on checks, installs terminals that 
allow key entry of any additional data, and installs devices 
for printing a sales draft receipt and to initiate reversals. A 
merchant also develops or installs a point-of-sale application 
for use with a check reader that can read and assemble the 
required information for transmission. Development of these 
application programs is known to those of skill in the art. A 
merchant also designates a bank account where electronic 
check funds can be deposited. Depending upon the telecom- 
munications service used, the merchant works with its 
acquirer to order and install the required telecommunica- 
tions configuration, and also works with its acquirer to agree 
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on the settlement process and reconfiguration procedures. 
The merchant also works with a third party agent to set up 
parameters for velocity checks (which may also be handled 
by an acquirer), sets up service options, and performs 
customer education and clerk training. 

[0050] The acquirer also performs certain tasks to enable 
POS Check Service transactions. For example, the acquirer 
provides hardware and software for communication with a 
merchant and a service organization which includes the 
ability to receive, reformat and send POS Check Service 
transactions. The acquirer also provides a unique merchant 
identifier for each merchant name and location that origi- 
nates transactions. The acquirer also selects service options 
to be supported, etc. 

[0051] A participating drawee bank is enabled to receive 
and respond to POS Check Service transactions. Also, the 
drawee bank is enabled to receive non-parsed MICR data 
and return parsed MICR data elements in transit routing 
number and check number fields. The drawee bank also 
develops a means for reporting POS Check Service trans- 
actions on the customer’s checking account statements. 

[0052] In addition to the above setup performed by a 
participating drawee bank, the third party also performs 
tasks such as arranging customer support for transactions 
they deny, arranging settlement with the switch for POS 
Check Service transactions they authorize and reconciliation 
of those transactions, setting up service options supported, 
providing reports or raw data for reporting, creating an ACH 
file on behalf of the acquiring banks, and providing addi- 
tional services to acquiring banks, such as image archiving 
and collection services. 

[0053] FIG. 4 is a more detailed illustration of paper 
check 106. As described above, check 106 may be any 
suitable personal check or even other types of checks as 
permitted by law. On the lower edge of check 106 is a line 
of information 252 commonly termed the MICR (magnetic 
ink character recognition) data. Included within this line are 
separation characters 254, 258, 262 and 266 which separate 
the various pieces of information. Information 256 is a 
sequence of characters that is the transit routing number, also 
termed the ABA number. Information 260 is a sequence of 
characters identifying the customer’s account number, 
termed the on-us data. Information 264 is a sequence of 
characters identifying the serial number of the check. As 
separators 254, 258, 262 and 266 are symbolic characters 
(also termed ''nonprintable characters”), they are typically 
translated later into alphanumeric characters. When the 
separators in the MICR data are later translated into alpha- 
numeric characters, they are typically translated to the 
characters “T”, “O”, “A” and “D” which is referred to as the 
raw TOAD format. Translation occurs because a computer 
systems cannot understand nonprintable characters, and this 
simple substitution allows the system (or another system) to 
eventually parse the information. 

[0054] FIG. 5 is a flow diagram describing how a request 
is initiated to convert a check at the point of sale. At this 
point in time, a customer is performing a transaction with a 
merchant and desires to make a purchase using a paper 
check for payment. In step 202 the clerk enters the amount 



of the transaction into one of the devices described in FIG. 
1. Of course, this amount may also be entered by the 
customer or may in some instances by automatically entered 
into a cash register using scanning or other known tech- 
niques. In step 206 the customer presents a paper check for 
payment. The check is in payment for goods or services and 
may not be filled out. The customer may receive cash back 
if the POS Check Service transaction is keyed for an amount 
above the purchase price. The cash back amount is uniquely 
identified in the POS Check Service authorization message. 

[0055] In step 310 the check is swiped through one of the 
devices described in FIG. 1. Preferably, the check contains 
MICR data and is swiped through a MICR device. Next, the 
device reads the raw MICR data from the bottom of the 
check in step 314. This data will include the transit routing 
number, the account number of the customer and the check 
serial number. The device translates the symbols into the 
appropriate alphanumeric characters (raw TOAD format). 
This translation may also occur at the acquirer. This trans- 
lation occurring at the device or at the acquirer is not an 
actual parsing, it is simple substitution of familiar alphanu- 
meric characters for nonprintable separation symbols. The 
translation assumes no knowledge about the structure of the 
MICR encoded information other than recognizing which 
nonprintable symbol matches with which alphanumeric 
character. As mentioned earlier other devices and readers 
may be used to obtain the necessary information for the 
paper check and in certain embodiments the paper check is 
not required but the identifying information is entered via a 
keypad or other means herein described. 

[0056] In an optional step, in step 322 additional customer 
information is entered into the device. This additional cus- 
tomer information may include identification such as driv- 
er’s license number, state identification number, military 
identification number, etc. Various types of customer infor- 
mation are presented in Table 1. This information is optional 
and variable and depends upon the individual requirements 
of the participating merchant, acquirers and third-party 
authorizing agents. 

[0057] As shown in Table 1, the processing code is used to 
identify the type of POS Check Service transaction that the 
merchant desires. A merchant may request that a check be 
converted, be verified and converted, or be guaranteed and 
converted. If a merchant requests Conversion Only, the 
transaction will be approved or declined by a participating 
bank on which the check is drawn or by a third-party 
authorizing agent with minimal account verification pro- 
cessing. If the merchant chooses Verification with Conver- 
sion, the request method will be routed to a participating 
bank on which the check is drawn or to an authorizing agent 
for verification of the probability that the check will be paid 
based on information available at the time of the request. 
The merchant will then receive either an approval or decline 
response. If the merchant chooses the Guarantee with Con- 
version option, the request message will be routed to a 
participating bank on which the check is drawn or to an 
authorizing agent to guarantee the check. The merchant will 
then receive either an approval or decline response. 
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TABLE 1 



Additional Customer Data — ^Private 



Field Name Usage 



ID Type and 
Number 



Date of Birth 

Telephone 

Number 

Response 

Source 

Reference 

Number 

Proprietary 

Response 

Information 

Receipt 

Information 

Call Back 

Information 



Identifies the type and number of the customer identification present at 
the point of sale. Used in the request. This field may be repeated as 
often as necessary, if information from multiple ID types is captured at 
the point of sale. The first two positions in this field are either a valid 
state code or an ID Type such as Military ID, Courtesy Card, social 
security number, proprietary card, military base, embassy or traveling 
merchant. If the value in the first two positions is a valid state code, then 
the number following it is either a valid driver’s license number or State 
ID. If the value in the fist two positions is a valid ID Type, then the 
number following it corresponds to the ID Type presented. 

Identifies a date of birth, field length, and contents. Used in the request. 
Identifies a telephone number, field length, and contents. Used in the 
request. 

A one-digit response source identifier returned by a non-bank authorizer 
in all responses. Used in the response. 

Identifies a reference number of any type, field length, and contents. 

Used in the response. 

Identifies proprietary response information defined by an authorizing 
agent, field length, and contents. Used in the response. 

Identifies customer receipt information, field length, and contents. Used 
in the response. 

Contains non-bank authorizer name, address, and customer service 
telephone number. The field is preferably returned by non-bank 
authorizers on declines of original requests. Used in the response. 



[ 0058 ] In step 326 the request message is built using the 
assembled information. The message can be assembled at 
the merchant or at the acquirer, but is typically assembled 
before being transferred to the service organization. The 
merchant also determines which service it desires, i.e.. 
Conversion Only, Verification with Conversion or Guarantee 
with Conversion. Regarding the different methods of ser- 
vice, a merchant may choose Conversion Only because his 
main objective is to eliminate paper processing and he 
anticipates a low-risk with the item. If a merchant is con- 
cerned about the authenticity of a check and wants to verify 
that funds are present in the customer’s checking account at 
the time of purchase, the merchant may choose Verification 
with Conversion because there is a greater likelihood that 
the merchant will be paid. If a merchant wants guaranteed 
payment of the item, he may choose Guarantee with Con- 
version, in which case the guarantor bears the liability even 
if the check is not honored. 



[ 0059 ] The POS Check Service message may be 
assembled using any desired format until it reaches the host 
connected to the service organization, at which point it must 
be formatted into the standard message format of the service 
organization, and includes such information as a merchant 
terminal identifier, a merchant identifier, a third-party iden- 
tifier, the amount of cash back desired, the RAW TOAD 
MICR data, the transaction amount, terminal capability 
information, information sufficient for clearing and settle- 
ment, and an indication of the service desired by the 
merchant. A list of possible information is presented in 
Tables 2 and 3. Other data fields include: Bitmap, secondary; 
transmission date/time; Systems trace audit number; local 
transaction time; local transaction date; settlement date; 
merchant type; acquiring institution country code; acquiring 
institution ID code; retrieval reference number; card accep- 
tor terminal ID; card acceptor ID code; card acceptor name/ 
location; transaction currency code; national POS geo- 
graphic data; network ID code; acquirer business ID; 
receiving institution ID code and additional trace data. 

TABLE 2 



Field Name 



Processing Code 



Request Message 

Use Suggested Data Requirements 

Identifies the type of POS Guarantee with Conversion = 
Check Service transaction. 03. 

Verification with Conversion = 
04. 

Conversion Only =18. 



Transaction Amount 
Point of Service Entry 
Mode Code 



Amount of transaction. 
Identifies the method used 
to capture the MICR data. 
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TABLE 2-continued 







Request Message 




Field Name 




Use 


Suggested Data Requirements 


POS Condition Code 


Serves as an identifier, in 


The POS Condition Code for 






conjunction with the 


POS Check Service transactions 






Processing Code. 


is 52 on all original full financial 
transactions. 


Check Settlement Code 


Provided by the service 


Switch Settlement Code = 1. 






organization in responses to 


ACH Settlement Code = 2. 






indicate the settlement 


Field not be present if the item 






disposition of the 
transaction. 


will not be settled. 


Additional Customer Data- 


May be used for any 


See Table 1. 


-Private 




customer identification 








information specifically 
required by an authorizes 




Additional POS Data 


A private-use field defined 








by the service organization 
to provide additional 
information about the point 
of sale or service. 




Other Amount, 


Should contain the cash 


The cash back amount should 


Transaction 




back amount from the 


not exceed the Transaction 






transaction, if any. 


Amount. 


Transaction Identifier 


Will contain a unique 


This field will be sent to 






transaction identifier 


transaction recipients and 






assigned by the service 


returned to transaction 






organization. 


originators. 


Receiving Institution ID 


Contain the BIN ID of the 


If the check is drawn on a 


Code 




third-party authorizer that 


participating drawee bank, the 






the originator wants to 


service organization will route 






receive the transaction. 


the transaction to that bank. 
Otherwise, the transaction will 
be sent to the designed third- 
party authorizer. 


Supporting Information 


Contains the MICR 


See Table 3. 






information from the 
customer’s check. 




[0060] 




TABLE 3 








MICR Information 




Field Name 


Data Content 


Format 


Data Type 


RM 


Identifies the data contents as 


Identifier 




unformatted MICR information. 


Data 


999 


Indicates the length of the MICR data 


Length 




contained in the field. 


Identifier 








MICR 


Contains the unaltered contents of The unformatted MICR data is 


Information 


the MICR line, with spaces preferably the same MICR line from the 

preserved, read from the customer’s check, including spaces, except that the 
check by a terminal. At a minimum, MICR symbols should be replaced as 
the Transit Routing Number and follows: 

Customer Account Number (On-us The Transit symbol is replaced by the 

field) should be present. letter “T” in either upper or lower case. 

Refer to Understanding and Design The On-us symbol is replaced by the 

Checks, ANSI Standard X9/TG-2 letter “O” in either upper or lower case. 




(1990). 


The Dash symbol is replaced by the 
letter “D” in either upper or lower case. 



[0061] FIGS. 6A, 6B and 6C are a flow diagram describ- 
ing the authorization and clearing of a transaction. Once a 
complete POS Check Service request message has been 
received by the host, and has been reformatted, the host 
sends the request message online to the service organization 



(switch) for central processing and routing to an authorizing 
endpoint. In step 402 the host reformats the message and 
sends it to the service organization. This reformatting is done 
in order to be in compliance with the switch interface 
speciflcations. 
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[0062] In step 406 the switch performs exclusion checking 
on the request. As part of the switch processing, a limited 
ABA exclusion verification is applied. In one embodiment, 
an ABA exclusion table is used. If the authorization request 
contains an ABA number (the transit routing number) that is 
included in the ABA exclusion table, the switch will imme- 
diately return a decline response to the host with an appro- 
priate response code. Included in the exclusion table are 
ABA numbers that identify government checks (J.S. Trea- 
sury and Federal Reserve), traveler’s checks, or an instru- 
ment with a non-check ABA number. ABA numbers are 
known to one of skill in the art and the table may be edited 
to exclude any types of checks based upon an ABA number. 
Preferably, the switch or its agent should be able to add or 
delete ABA numbers from the repository of online exclusion 
and offline translation data. These data repositories should 
be updated not less than daily. 

[0063] Preferably, the ABA number is extracted from the 
raw TOAD format MICR data without the need for parsing 
the data. Because it is known that ABA number is bounded 
by the “T” tag and is nine digits long, it is simple to extract 
the number for exclusion checking and later routing. Essen- 
tially, the switch “looks” at the ABA number but does not 
perform parsing (although it is possible for parsing to occur 
here). 

[0064] Preferably, the service organization also edits the 
transaction request to ensure valid data formats, and to 
insure the transaction complies with the business rules 
governing the service. Other checks such as duplicate check- 
ing are performed. The switch performs duplicate checking 
on originals to ensure merchants and acquirers do not submit 
identical requests. If the transaction passes these edits and 
checks, the service organization forwards the transaction to 
either a participating bank on which the check is drawn or 
to a third-party authorizing agent. 

[0065] Based upon a list of participating banks, in step 410 
the switch attempts to match the transit routing number with 
that of a participating drawee bank. If there is a match, then 
in step 414 the switch determines whether the service 
requested of the merchant matches a service provided by the 
drawee bank. If so, then in step 418 the settlement code in 
the request message is set to a “1” (or other symbol) to 



signify that settlement will eventually occur through the 
switch. The switch also generates a unique transaction 
identifier for the current transaction in step 430. Preferably, 
all transactions have an audit trail which ties together related 
transactions in a transaction set-thus, future reversals, voids, 
etc. can all be related to the original transaction. The unique 
transaction identifier may be used for this purpose. Next, this 
request message is sent to the participating drawee bank in 
step 434. If the switch determines the drawee is unavailable, 
a response for “Service Not Available” is sent to the mer- 
chant’s acquirer. 

[0066] In step 438, the bank handles the request as per the 
service requested by the merchant. The raw TOAD MICR 
data is first parsed as explained below. If Conversion Only 
is requested, then the bank may merely check to see that a 
valid account does exist at the bank, that the account has not 
been closed, and that the account is not fraudulent. (If 
invalid, a “Do not Honor” response is returned to the 
merchant’s acquirer.) The bank is not obligated to perform 
further checking or verification. When Verification with 
Conversion is requested, then in step 454 the bank not only 
verifies that the account is valid, but also that the amount of 
funds in the account is adequate for the transaction. In a 
preferred embodiment, a bank will also place a hold upon 
the account for the transaction amount in this step. If 
Guarantee with Conversion is desired, then in step 462 the 
bank will place a hold on the account for the amount of the 
transaction and will guarantee that the amount will be paid. 
In other words, the bank must pay the amount regardless of 
the account balance. 

[0067] Next, the bank generates a response message and 
returns it to the service organization. This response message 
contains a variety of information concerning the transaction; 
an example response message is shown in Table 4. Included 
within the response message is a response code generally 
indicating whether the request is approved. Examples of 
response codes are shown in Table 5. Table 5 shows the 
business reason for the response, response code, whether the 
response is approved or declined, and the responding end- 
point eligible to use each of the codes. Once switch 122 
receives the response message, it determines if there is an 
approval in step 470. 

TABLE 4 



Response Message Fields 



Field Name Data 



Format 



Response Code 



Additional Data, 
Private 

Support 
Information 
Field Identifier 



Contains a Response 
Code valid for POS 
Check Service 
transactions as shown 
in Table 5. 

No data is required in 
this field. 

This field contains: 

$V 



Any data that a check request respondent 
chooses to include in the message should be 
formatted as shown in Table 1. 

The POS Check Service field identifier appears 
in the first two types of the field, as shown. 
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TABLE 4-continued 



Response Message Fields 

Field Name Data Format 



Transit Routing The drawee bank’s 

Number Transit Routing 

Number (ABA 
Number). 



Customer The customer deposit 

Account Number account number 



Check Serial The check serial 

Number number of the check 

being converted. 



The POS Check Service field identifier appears 
in the first two bytes of the field, as shown. 

The Transit Routing Number has a fixed length 
of 9 numeric characters and may be formatted 
as follows: AB999dddd, where AB identifies 
the sub-field, 999 the length of the data, and 
dddd, the actual data contents. 

The customer deposit account number should 
be present, a maximum of 19 characters and 
preferably formatted as follows: 

AN999dddd, where AN identifies the sub- 
field, 999 the length of the data, and dddd, the 
actual data contents. 

The check serial number should be present, a 
maximum of 15 characters, and preferably 
formatted as follows: CK999dddd, where CK 
identifies the sub-field, 999 the length of the 
data, and dddd, the actual data content. Any of 
the alpha characters sent in this field in the 
request message (“t”, “o”. “d”) should be 
stripped out when the field is returned. 



[ 0068 ] 



TABLE 5 



Response Codes 





Response 


Approve/ 


Service 


Non-bank 


Participating 


Business Condition 


Code 


Decline 


Organization 


Authorizer 


Drawee Bank 


Unconditional 

Approval 


00 


A 




Y 


Y 


Invalid merchant ID 


03 


D 




Y 




Do not honor 


05 


D 




Y 


Y 


Invalid account 


14 


D 




Y 


Y 


No such issuer 


15 


D 


Y 






NSF 


51 


D 




Y 


Y 


Transaction not 


57 


D 


Y 


Y 


Y 


permitted 

Too much cash (over 
merchant or bank 


61 


D 




Y 


Y 


limit) 

Exceeds withdrawal 


65 


D 




Y 


Y 


frequency limit 
Unsolicited reversal 


76 


D 


Y 






Reversal received 


80 


D 


Y 






form denied request 
Issuer unavailable 


91 


D 


Y 






Routing error 


92 


D 


Y 


Y 


Y 


Duplicate 

Transaction 


94 


D 


Y 






System error 


96 


D 




Y 


Y 


Approval, keep first 
check 


TO 


A 




Y 




Check is OK, but 


T1 


D 




Y 




check cannot be 
converted 
Invalid Transit 


T2 


D 


Y 


Y 




Routing Number 
Amount greater than 
established service 


T3 


D 




Y 




limit 

Unpaid items, failed 
negative file check 


T4 


D 




Y 




Duplicate check 
number 


T5 


D 




Y 


Y 
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TABLE 5-continued 



Business Condition 


Response 

Code 


Response Codes 

Approve/ Service 

Decline Organization 


Non-bank 

Authorizer 


Participating 
Drawee Bank 


MICR error 


T6 


D 




Y 


Y 


Too many checks 
(over merchant or 
bank limit) 


T7 


D 




Y 


Y 



[0069] Returning for a moment to the “NO” branches of 
steps 410 and 414, if the transit routing does not match the 
table of participating banks, or the service requested by the 
merchant does not match the service provided by the par- 
ticipating bank, then in step 484 the settlement code in the 
request message is set to a “2” (or other suitable symbol) to 
signify that settlement will be through ACH because a 
third-party authorizing agent is used. The following steps 
describe actions occurring when the authorization request is 
sent to the third-party authorizing agent 126 in step 485. In 
some ways, the request is handled in a similar fashion as the 
participating drawee bank handles the request as described 
in FIG. 6B. Because the third party, however, does not have 
control over the customer’s account, it must use other means 
to provide verification and guarantee. In step 486 the request 
is handled as per the service request. The raw TOAD MICR 
data is first parsed as explained below. If the request is for 
Conversion Only, then in step 488 the third party, at a 
minimum, verifies that the check is eligible to be converted 
into an ACH item. 

[0070] If the request is for Verification with Conversion, 
then in step 490 the third party, at a minimum, performs 
velocity checks, searches their database of returned checks, 
verifies against risk models, etc., to determine the probabil- 



ity that the POS Check Service transaction amount will be 
paid by the customer’s bank. If the request is for Guarantee 
with Conversion, then in step 492 the third party performs 
velocity and database checks and will underwrite the amount 
of the request, guaranteeing payment even if the item is 
returned. Finally, in step 493 the third party generates a 
response message in much the same way as in step 466 and 
sends the response to the service organization. 

[0071] Returning to step 470 of FIG. 6B, once the 
response message has been received by the service organi- 
zation, it determines whether the transaction has been 
approved. More specifically, switch 122 processes response 
messages as shown in Table 6. If the transaction has been 
approved, the message is sent to the acquirer or merchant 
host who then reformats the message into the protocol used 
with the merchant, and sends the response message back to 
the merchant. If the transaction was not approved, the switch 
first removes the settlement code in step 478, indicating that 
the item is not settled, before sending the response message 
back to the acquirer or merchant. Once the response message 
is received by the merchant, the transaction is then com- 
pleted at the point of sale as described below. 



TABLE 6 



Switch Processing of Response Messages 



Field Name Contents 



Switch Processing 



Response 

Code 



Check 

Settlement 

Code 



Transaction 

Identifier 

Supporting 

Information 



The Response Code 
should be valid for POS 
Check Service 
transactions and valid 
for the sending party, as 
shown in Table 5. 
Switch will add under 
certain conditions. 



Contains the 
Transaction Identifier. 
Contains the Transit 
Routing Number, the 
Customer Account 
Number, and the Check 
Serial Number. 



If the Response Code is not valid, the switch will 
reject the transaction and will send a “decline” 
response to the originator of the response, with 
Response Code 91. 



If the response message carries an approval 
Response Code and passes all Switch edits, the 
Switch will add this field, indicating the 
settlement type for the transaction. A value of 1 
means that the Switch will settle the transaction. 

A value of 2 means that the transaction will settle 
through the Automated Clearing House (ACH). 
The Switch will restore the Transaction Identifier, 
if it is not returned in the response message. 

The Switch will edit the field for presence, correct 
formatting and required data. If the field is not 
present, the Switch will reject the transaction. If 
the transaction is approved and if the required 
Transit Routing Number, Customer Account 
Number, and Check Serial number are not 
present, or the formatting of the field is incorrect, 
the Switch will reject the transaction. If the 
transaction is approved and if the Transit Routing 




